Implémentation de la sécurité Cross-Origin : Meilleures pratiques pour la communication en JavaScript

Dans le web interconnecté d'aujourd'hui, les applications JavaScript ont fréquemment besoin d'interagir avec des ressources provenant de différentes origines (domaines, protocoles ou ports). Cette interaction est régie par la politique de même origine (Same-Origin Policy) du navigateur, un mécanisme de sécurité crucial conçu pour empêcher les scripts malveillants d'accéder à des données sensibles au-delà des frontières de domaine. Cependant, une communication légitime entre origines différentes est souvent nécessaire. C'est là qu'intervient le Cross-Origin Resource Sharing (CORS). Cet article offre un aperçu complet du CORS, de son implémentation et des meilleures pratiques pour une communication cross-origin sécurisée en JavaScript.

Comprendre la politique de même origine (Same-Origin Policy)

La politique de même origine (Same-Origin Policy ou SOP) est un concept de sécurité fondamental dans les navigateurs web. Elle restreint les scripts exécutés sur une origine d'accéder à des ressources d'une origine différente. Une origine est définie par la combinaison du protocole (par exemple, HTTP ou HTTPS), du nom de domaine (par exemple, example.com) et du numéro de port (par exemple, 80 ou 443). Deux URL ont la même origine uniquement si ces trois composants correspondent exactement.

Par exemple :

• http://www.example.com et http://www.example.com/path : Même origine
• http://www.example.com et https://www.example.com : Origine différente (protocole différent)
• http://www.example.com et http://subdomain.example.com : Origine différente (domaine différent)
• http://www.example.com:80 et http://www.example.com:8080 : Origine différente (port différent)

La SOP est une défense essentielle contre les attaques de Cross-Site Scripting (XSS), où des scripts malveillants injectés dans un site web peuvent voler des données utilisateur ou effectuer des actions non autorisées au nom de l'utilisateur.

Qu'est-ce que le Cross-Origin Resource Sharing (CORS) ?

CORS est un mécanisme qui utilise des en-têtes HTTP pour permettre aux serveurs d'indiquer quelles origines (domaines, schémas ou ports) sont autorisées à accéder à leurs ressources. Il assouplit essentiellement la politique de même origine pour des requêtes cross-origin spécifiques, permettant une communication légitime tout en protégeant contre les attaques malveillantes.

CORS fonctionne en ajoutant de nouveaux en-têtes HTTP qui spécifient les origines autorisées et les méthodes (par exemple, GET, POST, PUT, DELETE) permises pour les requêtes cross-origin. Lorsqu'un navigateur effectue une requête cross-origin, il envoie un en-tête Origin avec la requête. Le serveur répond avec un en-tête Access-Control-Allow-Origin qui spécifie la ou les origines autorisées. Si l'origine de la requête correspond à la valeur de l'en-tête Access-Control-Allow-Origin (ou si la valeur est *), le navigateur autorise le code JavaScript à accéder à la réponse.

Comment fonctionne le CORS : Une explication détaillée

Le processus CORS implique généralement deux types de requêtes :

1. Requêtes simples : Ce sont des requêtes qui répondent à des critères spécifiques. Si une requête remplit ces conditions, le navigateur envoie directement la requête.
2. Requêtes pré-vérifiées (Preflighted) : Ce sont des requêtes plus complexes qui nécessitent que le navigateur envoie d'abord une requête "preflight" OPTIONS au serveur pour déterminer si la requête réelle peut être envoyée en toute sécurité.

1. Requêtes simples

Une requête est considérée comme "simple" si elle remplit toutes les conditions suivantes :

• La méthode est GET, HEAD ou POST.
• Si la méthode est POST, l'en-tête Content-Type est l'un des suivants :
• application/x-www-form-urlencoded
• multipart/form-data
• text/plain
• Aucun en-tête personnalisé n'est défini.

Exemple d'une requête simple :

GET /resource HTTP/1.1
Origin: http://www.example.com

Exemple d'une réponse de serveur autorisant l'origine :

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.example.com
Content-Type: application/json

{
  "data": "Quelques données"
}

Si l'en-tête Access-Control-Allow-Origin est présent et que sa valeur correspond à l'origine de la requête ou est définie sur *, le navigateur autorise le script à accéder aux données de la réponse. Sinon, le navigateur bloque l'accès à la réponse et un message d'erreur s'affiche dans la console.

2. Requêtes pré-vérifiées (Preflighted)

Une requête est considérée comme "pré-vérifiée" si elle ne remplit pas les critères d'une requête simple. Cela se produit généralement lorsque la requête utilise une méthode HTTP différente (par exemple, PUT, DELETE), définit des en-têtes personnalisés ou utilise un Content-Type autre que les valeurs autorisées.

Avant d'envoyer la requête réelle, le navigateur envoie d'abord une requête OPTIONS au serveur. Cette requête "preflight" inclut les en-têtes suivants :

• Origin : L'origine de la page émettrice.
• Access-Control-Request-Method : La méthode HTTP qui sera utilisée dans la requête réelle (par exemple, PUT, DELETE).
• Access-Control-Request-Headers : Une liste séparée par des virgules des en-têtes personnalisés qui seront envoyés dans la requête réelle.

Exemple d'une requête preflight :

OPTIONS /resource HTTP/1.1
Origin: http://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header, Content-Type

Le serveur doit répondre à la requête OPTIONS avec les en-têtes suivants :

• Access-Control-Allow-Origin : L'origine qui est autorisée à effectuer la requête (ou * pour autoriser n'importe quelle origine).
• Access-Control-Allow-Methods : Une liste séparée par des virgules des méthodes HTTP autorisées pour les requêtes cross-origin (par exemple, GET, POST, PUT, DELETE).
• Access-Control-Allow-Headers : Une liste séparée par des virgules des en-têtes personnalisés qui sont autorisés à être envoyés dans la requête.
• Access-Control-Max-Age : Le nombre de secondes pendant lesquelles la réponse preflight peut être mise en cache par le navigateur.

Exemple d'une réponse de serveur à une requête preflight :

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: X-Custom-Header, Content-Type
Access-Control-Max-Age: 86400

Si la réponse du serveur à la requête preflight indique que la requête réelle est autorisée, le navigateur enverra alors la requête réelle. Sinon, le navigateur bloquera la requête et affichera un message d'erreur.

Implémenter le CORS côté serveur

Le CORS est principalement implémenté côté serveur en définissant les en-têtes HTTP appropriés dans la réponse. Les détails spécifiques de l'implémentation varieront en fonction de la technologie côté serveur utilisée.

Exemple avec Node.js et Express :

const express = require('express');
const cors = require('cors');
const app = express();

// Active le CORS pour toutes les origines
app.use(cors());

// Alternativement, configurez le CORS pour des origines spécifiques
// const corsOptions = {
//   origin: 'http://www.example.com'
// };
// app.use(cors(corsOptions));

app.get('/resource', (req, res) => {
  res.json({ message: 'Ceci est une ressource compatible CORS' });
});

app.listen(3000, () => {
  console.log('Serveur en écoute sur le port 3000');
});

Le middleware cors simplifie le processus de définition des en-têtes CORS dans Express. Vous pouvez activer le CORS pour toutes les origines en utilisant cors() ou le configurer pour des origines spécifiques en utilisant cors(corsOptions).

Exemple avec Python et Flask :

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/resource")
def hello():
    return {"message": "Ceci est une ressource compatible CORS"}

if __name__ == '__main__':
    app.run(debug=True)

L'extension flask_cors offre un moyen simple d'activer le CORS dans les applications Flask. Vous pouvez activer le CORS pour toutes les origines en passant app à CORS(). La configuration pour des origines spécifiques est également possible.

Exemple avec Java et Spring Boot :

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/resource")
                .allowedOrigins("http://www.example.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("Content-Type", "X-Custom-Header")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

Dans Spring Boot, vous pouvez configurer le CORS en utilisant un WebMvcConfigurer. Cela permet un contrôle fin sur les origines, méthodes, en-têtes autorisés et autres paramètres CORS.

Définir les en-têtes CORS directement (Exemple générique)

Si vous n'utilisez aucun framework, vous pouvez définir les en-têtes directement dans votre code côté serveur (par exemple, PHP, Ruby on Rails, etc.) :

Meilleures pratiques CORS

Pour garantir une communication cross-origin sécurisée et efficace, suivez ces meilleures pratiques :

1. Évitez d'utiliser Access-Control-Allow-Origin: * en production : Autoriser toutes les origines à accéder à vos ressources peut être un risque de sécurité. Spécifiez plutôt les origines exactes qui sont autorisées.
2. Utilisez HTTPS : Utilisez toujours HTTPS pour l'origine émettrice et l'origine du serveur afin de protéger les données en transit.
3. Validez les entrées : Validez et nettoyez toujours les données reçues des requêtes cross-origin pour prévenir les attaques par injection.
4. Implémentez une authentification et une autorisation appropriées : Assurez-vous que seuls les utilisateurs autorisés peuvent accéder aux ressources sensibles.
5. Mettez en cache les réponses preflight : Utilisez Access-Control-Max-Age pour mettre en cache les réponses preflight et réduire le nombre de requêtes OPTIONS.
6. Envisagez d'utiliser les informations d'identification (credentials) : Si votre API nécessite une authentification avec des cookies ou une authentification HTTP, vous devez définir l'en-tête Access-Control-Allow-Credentials sur true côté serveur et l'option credentials sur 'include' dans votre code JavaScript (par exemple, en utilisant fetch ou XMLHttpRequest). Soyez extrêmement prudent en utilisant cette option, car elle peut introduire des vulnérabilités de sécurité si elle n'est pas gérée correctement. De plus, lorsque Access-Control-Allow-Credentials est défini sur true, Access-Control-Allow-Origin ne peut pas être défini sur "*". Vous devez spécifier explicitement la ou les origines autorisées.
7. Révisez et mettez à jour régulièrement la configuration CORS : À mesure que votre application évolue, révisez et mettez à jour régulièrement votre configuration CORS pour vous assurer qu'elle reste sécurisée et répond à vos besoins.
8. Comprenez les implications des différentes configurations CORS : Soyez conscient des implications de sécurité des différentes configurations CORS et choisissez celle qui est appropriée pour votre application.
9. Testez votre implémentation CORS : Testez minutieusement votre implémentation CORS pour vous assurer qu'elle fonctionne comme prévu et qu'elle n'introduit aucune vulnérabilité de sécurité. Utilisez les outils de développement du navigateur pour inspecter les requêtes et réponses réseau, et utilisez des outils de test automatisés pour vérifier le comportement du CORS.

Exemple : Utilisation de l'API Fetch avec CORS

Voici un exemple d'utilisation de l'API fetch pour effectuer une requête cross-origin :

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors', // Indique au navigateur qu'il s'agit d'une requête CORS
  headers: {
    'Content-Type': 'application/json',
    'X-Custom-Header': 'value'
  }
})
.then(response => {
  if (!response.ok) {
    throw new Error('La réponse du réseau n'était pas OK');
  }
  return response.json();
})
.then(data => {
  console.log(data);
})
.catch(error => {
  console.error('Un problème est survenu avec l'opération fetch :', error);
});

L'option mode: 'cors' indique au navigateur qu'il s'agit d'une requête CORS. Si le serveur n'autorise pas l'origine, le navigateur bloquera l'accès à la réponse, et une erreur sera levée.

Si vous utilisez des informations d'identification (par exemple, des cookies), vous devez définir l'option credentials sur 'include' :

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors',
  credentials: 'include', // Inclure les cookies dans la requête
  headers: {
    'Content-Type': 'application/json'
  }
})
.then(response => {
  // ...
});

CORS et JSONP

JSON with Padding (JSONP) est une ancienne technique pour contourner la politique de même origine. Elle fonctionne en créant dynamiquement une balise <script> qui charge des données depuis un domaine différent. Bien que JSONP puisse être utile dans certaines situations, il présente des limitations de sécurité importantes et doit être évité lorsque cela est possible. CORS est la solution privilégiée pour la communication cross-origin car il offre un mécanisme plus sécurisé et flexible.

Différences clés entre CORS et JSONP :

• Sécurité : CORS est plus sécurisé que JSONP car il permet au serveur de contrôler quelles origines sont autorisées à accéder à ses ressources. JSONP ne fournit aucun contrôle d'origine.
• Méthodes HTTP : CORS prend en charge toutes les méthodes HTTP (par exemple, GET, POST, PUT, DELETE), tandis que JSONP ne prend en charge que les requêtes GET.
• Gestion des erreurs : CORS offre une meilleure gestion des erreurs que JSONP. Lorsqu'une requête CORS échoue, le navigateur fournit des messages d'erreur détaillés. La gestion des erreurs JSONP se limite à détecter si le script a été chargé avec succès.

Dépannage des problèmes CORS

Les problèmes CORS peuvent être frustrants à déboguer. Voici quelques conseils de dépannage courants :

• Vérifiez la console du navigateur : La console du navigateur fournira généralement des messages d'erreur détaillés sur les problèmes CORS.
• Inspectez les requêtes réseau : Utilisez les outils de développement du navigateur pour inspecter les en-têtes HTTP de la requête et de la réponse. Vérifiez que les en-têtes Origin et Access-Control-Allow-Origin sont correctement définis.
• Vérifiez la configuration côté serveur : Revérifiez votre configuration CORS côté serveur pour vous assurer qu'elle autorise les bonnes origines, méthodes et en-têtes.
• Videz le cache du navigateur : Parfois, les réponses preflight mises en cache peuvent causer des problèmes CORS. Essayez de vider le cache de votre navigateur ou d'utiliser une fenêtre de navigation privée.
• Utilisez un proxy CORS : Dans certains cas, vous pourriez avoir besoin d'utiliser un proxy CORS pour contourner les restrictions CORS. Cependant, soyez conscient que l'utilisation d'un proxy CORS peut introduire des risques de sécurité.
• Recherchez les erreurs de configuration : Recherchez les erreurs de configuration courantes telles qu'un en-tête Access-Control-Allow-Origin manquant, des valeurs incorrectes pour Access-Control-Allow-Methods ou Access-Control-Allow-Headers, ou un en-tête Origin incorrect dans la requête.

Conclusion

Le Cross-Origin Resource Sharing (CORS) est un mécanisme essentiel pour permettre une communication cross-origin sécurisée dans les applications JavaScript. En comprenant la politique de même origine, le fonctionnement de CORS et les divers en-têtes HTTP impliqués, les développeurs peuvent implémenter CORS efficacement pour protéger leurs applications contre les vulnérabilités de sécurité tout en autorisant les requêtes cross-origin légitimes. Suivre les meilleures pratiques pour la configuration CORS et réviser régulièrement votre implémentation sont cruciaux pour maintenir une application web sécurisée et robuste.

Ce guide complet fournit une base solide pour comprendre et implémenter le CORS. N'oubliez pas de consulter la documentation officielle et les ressources pour votre technologie côté serveur spécifique afin de vous assurer que vous implémentez le CORS correctement et en toute sécurité.

Ressources supplémentaires

• MDN Web Docs : Cross-Origin Resource Sharing (CORS)
• W3C : Cross-Origin Resource Sharing (CORS)
• PortSwigger Web Security Academy : CORS